Skip to content

Conversation

@cbiffle
Copy link
Collaborator

@cbiffle cbiffle commented May 9, 2022

This adds support for one of the two cores. Note that you can't actually use this to flash it; I'm currently feeding the eval board UF2 files. The upstream elf2uf2 tool is buggy and won't accept our ELF files, so, I wrote a new one. Basically, don't get too excited yet.

cbiffle added 6 commits May 13, 2022 18:55
As of fairly recently, you need to provide a full flash configuration to
be able to even build an archive for a board. This makes it annoying to
bring up new chips.

This change makes the build system tolerate this condition, and simply
doesn't include flashing instructions in the archive.
This can blink an LED on the Pi Pico board and...that's it.
- More docs
- Access to the rest of GPIO configuration, including function select.
The LED pin mapping is not rp2040-specific, but Pi Pico specific, so it
now hinges on the board target instead of the processor.
@moosingin3space
Copy link

Hi, I actually attempted this a few months ago as an attempt to learn Hubris! Some useful things I discovered:

  1. probe-rs supports the RP2040 "normally" -- via an external JTAG/SWD probe. I used a CMSIS-DAP with both a defmt/RTIC demo application and with my (not-really-working) RP2040 port of Hubris.
  2. I was able to use RTT (via the defmt/rtt_target crates) in order to log messages to the host. I noticed Hubris has ITM support for the system log, would an RTT backend be useful? Could possibly integrate it with Humility (via the probe-rs libraries) to have support for RP2040 debugging.

@mchodzikiewicz
Copy link
Contributor

This is also what my thinking was reading the docs - why no rtt when there is such an excellent support from knurling.rs and one pin less to be used

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants